Hardware Plugin Validation & Status Reporting

Summary

This PR adds runtime validation for hardware plugin names in PtpConfig and reports configuration errors directly to the PtpConfig CR status. When users accidentally misconfigure plugin names (e.g., typo e81 instead of e810), the daemon now:

1. Detects the invalid plugin name at runtime
2. Reports a clear warning to the PtpConfig status via HardwarePluginConfigurationWarning condition
3. Automatically clears the warning when the configuration is corrected

Problem

Previously, if a user made a typo in the hardware plugin configuration section of a PtpConfig, the daemon would silently fail to configure the hardware but continue running. This made debugging configuration issues difficult.

Example of a typo that would go unnoticed:

plugins:
  e81:  # Typo! Should be "e810"
    enableDefaultConfig: false

Solution

The PluginManager now validates plugin names against registered plugins and uses a dynamic client to update the PtpConfig status when errors are found.

New Status Condition

status:
  conditions:
    - type: HardwarePluginConfigurationWarning
      status: "True"
      reason: InvalidPluginName
      message: "Profile 'my-profile' contains unrecognized hardware plugin(s): [e81]. Valid plugins are: [e810 e825 e830 ntpfailover]"

Files Changed

Implementation Details

PluginManager Changes (pkg/plugin/plugin.go)

• Added RestConfig and Namespace fields for dynamic client creation
• New methods:
  • ValidateAndReportPluginErrors() - Main validation entry point
  • updatePtpConfigStatusWithPluginError() - Adds warning condition
  • clearPtpConfigPluginWarning() - Removes warning when fixed
  • removePluginWarningCondition() - Helper for condition removal

Daemon Integration (pkg/daemon/daemon.go)

• Validation runs at the end of applyNodePTPProfiles() after profiles are applied
• PluginManager receives RestConfig and Namespace during daemon initialization

Testing

Unit Tests

go test ./pkg/plugin/... -v

Integration Testing

1. Apply invalid config:

kubectl apply -f test/ptpconfig-invalid-plugin-test.yaml

2. Check for warning condition:

kubectl get ptpconfig test-invalid-plugin -n openshift-ptp -o jsonpath='{.status.conditions}' | jq

3. Expected output:

[{
  "type": "HardwarePluginConfigurationWarning",
  "status": "True",
  "reason": "InvalidPluginName",
  "message": "Profile 'test-invalid-plugin' contains unrecognized hardware plugin(s): [e81]. Valid plugins are: [e810 e825 e830 ntpfailover]"
}]

4. Fix the plugin name and verify warning is cleared:

kubectl patch ptpconfig test-invalid-plugin -n openshift-ptp --type='json' \
  -p='[{"op": "replace", "path": "/spec/profile/0/plugins", "value": {"e810": {"enableDefaultConfig": false}}}]'

# Wait ~30s for next config cycle, then verify condition is removed
kubectl get ptpconfig test-invalid-plugin -n openshift-ptp -o jsonpath='{.status.conditions}'

Notes

• Uses Kubernetes dynamic client to avoid requiring API changes in ptp-operator
• Validation occurs when profiles are applied (not on a periodic ticker)
• Valid plugin names are determined by registered plugins in PluginManager